The present invention, in some embodiments thereof, relates to a flash memory and to cache flushing, and, more particularly, but not exclusively, to cache flushing in the case of multiple copying of the same data from the cache for stable storage.
The present embodiments are applicable to flash storage systems that on the one hand use a self-caching mechanism for data received from a host, and on the other hand use flash memory technology that requires data to be copied more than once into the memory die in order to achieve reliable and interference-free storage of the data. In such systems the prior art practice for flushing the cache involved copying data from the cache storage area to the main storage area in order to make room for additional data. Such cache flushing involves the sequence of operations by the flash controller that is described in FIG. 3 below. The procedure is summarized as follows, making use of the reference numerals of FIG. 3.
60. Select what portion of the data currently in the cache is to be flushed.
62. Read the selected data from the cache memory cells to the flash memory data register.
64. Transfer the data from the flash memory data register to the flash controller.
66. Modify the data, at the controller, for long-range storage in the main storage area. This may involve conditioning with error correction codes, executing interleaving schemes, adding control fields, etc.
68. Transfer the modified data from the flash controller to the flash memory data register
70. Write the modified data from the data register to the main storage area cells
72. Repeat steps 62-72 once for each additional time the data have to be re-written into the main storage area.
The above procedure is clearly inefficient as it repeats the data transfer in and out of the flash memory die multiple times, and the data processing required for modifying the data is likewise unnecessarily repeated. It is thus desirable to reduce the time wasted due to this inefficiency.
One might think the problem can be solved by writing the data multiple times from the flash data register to the main storage area cells, without sending the data each time from the controller to the data register. This, however, will not work for the following reasons:
1. In most flash memory dies the data register contents are destroyed during the register-to-array writing process.
2. Even if the data in the register is preserved during writing, the typical sequence to be followed when writing the data multiple times interleaves the writing of multiple pages, so that after writing a first page a first time, a second page has to be written before the first page is written a second time. Therefore the data cannot be preserved in the data register between multiple writes of the same data.
One reason that the same data may need to be written multiple times is due to the interference effect of neighboring Flash memory cells in high density flash constructions. Such interference is dependent on the actual data in neighboring cells and therefore can only be accounted for at write time. Thus it is necessary to actually write the data into the Flash memory once, write the neighboring cells and then rewrite the same data. However, for the reasons noted, the data is most likely to have been removed from the data register before it can be written a second time.
Examples for self-caching flash storage systems are U.S. Pat. No. 5,930,167 to Lee et al. and U.S. patent application Ser. No. 11/318,906 to Lasser et al.
Examples for flash storage systems that require multiple writing of the same data can be seen in U.S. Pat. No. 6,522,580 to Chen et al. and U.S. Pat. No. 7,149,111 to Murin et al.
The common approach in the prior art is the one described above with respect to FIG. 3. U.S. patent application Ser. No. 12/005,368 (hereinafter '368) describes an approach to a similar problem—its solution is to apply the modifications to the data, in that case error correction and control (ECC) encoding, prior to storing it in the cache, and then doing the cache flushing using the flash die's copy-back operation that allows copying the data from the cache to the main area without sending it out to the flash controller. However, '368 suffers from the following drawbacks that make its solution less practical in many cases:
1. It requires the cache area to have enough storage space for storing the data accompanied by both cache-related metadata and main-area-related metadata (error codes, control fields).
2. It requires that the processing to be applied to the data be known at the time of placing the data into the cache. In practice, however, the processing is not fully known until cache flushing time. For example the data to be stored in the main area may require to be accompanied by a control field dependent on the physical address of the data. However the physical address is only determined at flushing time, and not at the time when the data is placed in the cache.
Another approach to the above problems may involve keeping a copy of the modified data in the flash controller and thus save on modifying the data again and again.
This approach however suffers from the following drawbacks:
1. It does solve the repeated data processing problem, but it does not solve the repeated data transfer problem.
2. It requires the controller to have extra memory for keeping the modified data while other data is being handled between successive writes of the modified data (as explained above). Depending on the exact writing sequence dictated by the flash memory, this requirement might translate into a large amount of controller memory that may increase the controller's price.
However, whenever the data is rewritten, inefficient utilization of the Flash controller and unnecessary data transfers are made, as described above.